Low Budget Performance, Part 2 - Mailing list pgsql-performance

From eric soroos
Subject Low Budget Performance, Part 2
Date
Msg-id 25877025.1173728234@[4.42.179.151]
Whole thread Raw
Responses Re: Low Budget Performance, Part 2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
In our first installment a couple of weeks ago, I was asking about low end hardware optimizations, it got into
ide/scsi,memory, and drive layout issues. 

I've been wondering more about the IDE/SCSI difference for low end hardware, and since my dev worksatation needed more
harddrive space, I have a good opportunity to aquire hardware and run some benchmarks.  

The machine:

Sawtooth g4/400, X 10.1.5, PG 7.2.1 from entropy.ch's packages.
IDE: udma66 controller, ibm 7200rpm 15 gig deskstar. On it's own controller on the motherboard.  This is the system
drive.
SCSI: Ultra160 ATTO Apple OEM PCI controller, Ultra320 cable, IBM 10k rpm 18 gig Ultrastar drive.  Total scsi chain
price= $140.  

pgbench was run from a machine (debian woody) on the local net segment that could actually compile pgbench.

The IDE drive is about 2 years old, but was one of the fastest at the time. The SCSI drive is new but of inexpensive
provenance.Essentially, roughly what I can afford if I'm doing a raid setup. 

My gut feeling is that this is stacked against the IDE drive. It's older lower rpm technology, and it has the system
andpg binaries on it. The ide system in OSX probably has more development time behind it than scsi. 

However, the results say something a little different.

Running pgbench with: scaling factor=1, # transactions = 100, and #clients =1,2,3,5,10,15  The only difference that was
morethan the scatter between runs was at 15 clients, and the SCSI system was marginally better. (diff of 1-2 tps at ~
60sustained) 

Roughly, I'm seeing the following performance

clients   SCSI   IDE (tps)
1         83     84
2         83     83
3         79     79
5         77     76
10        73     73
15        66     64

I'm enclined to think that the bottleneck is elsewhere for this system and this benchmark, but I'm not sure where.
Probablyprocessor or bandwidth to memory.  

My questions from this excercise are:

1) do these seem like reasonable values, or would you have expected a bigger difference.
2) Is pgbench the proper test? It's not my workload, but it's also easily replicated at other sites.
3) Does running remotely make a difference?

eric




pgsql-performance by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: [HACKERS] Realtime VACUUM, was: performance of
Next
From: Tom Lane
Date:
Subject: Re: Low Budget Performance, Part 2